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1.0  INTRODUCTION 

This  chapter  explains  the  purpose  of  the  convention,  the  scope  of 
the  guidance,  and  provides  an  explanation  of  how  to  use  the 
convention. 

1.1  PURPOSE  OF  THE  CONVENTION 

The  convention  provides  general  guidance  on  the  implementation 
of  American  National  Standards  Institute  (ANSI)  Accr^ited  Stand¬ 
ards  Committee  (ASC)  XI2  electronic  data  interchange  (EDI) 
standards  within  automated  information  systems  (AIS)  and  infor¬ 
mation  interchange  procedures  that  require  the  collection,  report¬ 
ing,  and/or  exchange  of  data  needed  to  perform  defense  missions. 

1.2  SCOPE 

The  guidance  is  provided  for  two  components.  First,  it  may  be 
used  by  organizational  elements  of  the  DoD  community.  It  may 
also  be  useful  to  organizations  external  to  DoD  that  exchange  data 
with  the  DoD  community  in  the  course  of  their  business  relation¬ 
ships. 

The  DoD  community  encompasses  the  Military  Services,  Organiza¬ 
tions  of  the  Joint  Chiefs  of  Staff,  Unified  and  Specified  Commands, 
Office  of  the  Secretary  of  Defense,  and  the  Defense  agencies.  (That 
community  is  collectively  referred  to  as  the  DoD  Components.) 

Organizational  entities  external  to  DoD  include  (a)  non-Govem- 
ment  organizations,  both  commercial  and  nonprofit;  (b)  Federal 
agencies  of  the  United  States  Government  other  than  DoD; 
(c)  local  and  state  governments;  (d)  foreign  national  governments; 
and  (e)  international  government  organizations. 

The  draft  convention  published  in  this  document  is  for  trial  use 
and  comment.  DoD  Components  must  submit  to  the  DoD  EDI 
Executive  Agent  (EA)  their  data  requirements  that  are  not  covered 
in  the  conventions  as  soon  as  possible,  as  indicated  in  Chapter  2.0, 
Section  2.1. 

1.3  RESPONSIBLE  ENTITY 

The  Defense  Logistics  Agency  (DLA)  is  DoD’s  Executive  Agent 
for  implementing  and  maintaining  Defense-wide  programs  for 
(a)  EDI  in  accordance  with  DepSecDef  memorandum  of  May  24, 
1988,  Subject:  Electronic  Data  Interchange  of  Business-Related 
Transactions:  and  (b)  Protection  of  Logistics  Unclassified/Sensi- 
tive  Systems  (PLUS)  in  accordance  with  Assistant  Secretary  of 
Defense  (Production  and  Logistics)  [ASD(P&L)]  memorandum  of 
November  21,  1989,  Subject:  Production  and  Logistics  Task 
Group  for  Data  Protection.  Publication  of  these  conventions  is 
based  upon  this  authority.  Sec  Chapter  2.0  .Maintenance,  Section  2.1 
for  office  point  of  contact 
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1.4  HOW  TO  USE  THE  IMPLEMENTATION 
CONVENTION 

The  main  topics  and  structures  of  this  document  conform  to  the 
EDI  Implementation  Reference  Manual  Guidelines  document  that 
was  developed  by  a  task  group  of  the  subcommittee  on  education 
and  implementation  of  the  ASC  XI 2.  The  purpose  of  having 
agreed-upon  topics  and  structure  is  to  facilitate  reference  by  the 
many  industry  and  DoD  personnel  who  are  involved  in  implement¬ 
ing  the  uniform  standards  for  electronic  interchange  of  business 
transactions. 

1.4.1  Conventions,  Standards,  and  Guidelines 

The  terms  conventions,  standards,  and  guidelines  are  used 
throughout  the  document  and  are  defined  as  follows; 

•  Conventions  are  the  common  practices  and/or  interpretations 
of  the  use  of  ASC  X12  standards.  Conventions  define  what  is 
included  in  a  specific  implementation  of  an  ASC  X12  standard. 

•  Standards  are  the  technical  documentation  approved  by 
ASC  X12;  specifically,  transaction  sets,  segments,  data  ele¬ 
ments,  code  sets,  and  interchange  control  structure.  Standards 
provide  the  structure  for  each  ASC  X12  document. 

•  Guidelines  are  instructions  on  the  use  of  EDI.  They  provide 
additional  information  to  assist  in  conducting  EDI.  Guidelines 
are  intended  to  provide  assistance  and  should  not  be  your  sole 
source  of  information. 

1 .4.1 .1  Who  Develops  the  Conventions? 

Conventions  result  from  a  joint  effort  between  business,  technical, 
and  EDI  ASC  X12  standards  experts.  The  business  data  require¬ 
ment  is  defined,  a  transaction  set  is  selected,  and  the  data  require¬ 
ment  is  then  identifled  with  data  elements  in  the  transaction  set. 
A  convention  is  usually  developed  before  any  computer  EDI  sys¬ 
tems  development  work  and  serves  as  a  design  document  when  the 
development  process  begins. 

1 .4.1 .2  Why  Use  a  Convention? 

To  create  an  ASC  X12  transaction,  a  user  must  know  the  data 
requirements,  understand  the  ASC  XI 2  standard,  and  be  able  to 
use  that  information  to  develop  an  interface  program  between  the 
computer  application  and  the  ASC  X12  translator.  The  necessary 
information  to  perform  this  task  is  contained  in  the  convention 
document.  Users  who  follow  the  convention  will  create  a  transac¬ 
tion  set  that  all  DoD  users  understand. 

1 .4.1 .3  Who  Needs  a  Convention? 

System  analysts  and  application  programmers  who  plan  to  create 
or  read  ASC  X12  transactions  use  a  convention  to  aid  in  interface 
software  design.  The  convention  will  help  the  programmer  and 
analyst  identify  where  their  application  data  requirement  should  be 
carried  in  an  ASC  X12  transaction  set. 
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1 .4.4.4  Can  I  Develop  a  Convention? 

Cunventions  already  exist  for  some  of  the  most  common  business 
practices.  Copies  of  existing  conventions  can  be  acquired  through 
your  organization’s  EDI  coordinator  at  the  start  of  an  EDI  project. 
If  you  Hnd  no  conventions  for  the  business  practice  you  are  about 
to  implement,  your  EDI  coordinator  should  contact  the  DoD  Ex¬ 
ecutive  Agent  for  EDI.  See  Chapter  2.0,  Maintenance,  Section  2.1 
for  the  point  of  contact. 

1.4.2  Documentation  Of  Conventions 

Conventions  are  adopted  from,  and  are  intended  to  be  in  confor¬ 
mance  with,  ANSI  ASC  X12  standards  or  ASC  X12  Draft  Stand¬ 
ards  for  Trial  Use  (DSTU). 

1. 4.2.1  Transaction  Set 

Figure  1.4-1  provides  an  example  of  a  transaction  set  table.  The 
transaction  set  defines  information  of  business  or  strategic  sig¬ 
nificance  and  consists  of  a  transaction  set  header  segment,  one  or 
more  data  segments  in  a  specified  order,  and  a  transaction  set 
trailer  segment.  The  actual  ASC  X12  standard  as  it  appears  in  the 
official  ASC  X12  standards  manual  is  presented  on  the  right  side 
of  the  page.  This  standard  also  includes  both  syntax  notes  and 
comments.  The  specific  DoD  usage  designator  is  presented  on  the 
left  side  of  the  page. 

The  designation  “N/U”  aqipears  in  the  left  column  if  DoD  does  not 
use  the  specific  segment.  A  page  number  will  appear  if  the  segment 
is  used. 

1. 4.2.2  Transaction  Set  Segment 

Figure  1.4-2  is  an  example  of  a  transaction  set  segment. 

DoD  usage  is  specified  on  the  left  side  of  the  page.  For  identifier 
(ID)  —  type  data  elements,  acceptable  code  values  are  listed  on 
the  right  side  of  the  page  under  the  definitions  of  the  element. 

DoD  notes,  reflecting  how  the  convention  is  to  be  used  appear  on 
the  right  side  of  the  page  at  the  segment  level  or  the  data  element 
level. 

The  following  definitions  are  for  use  in  interpreting  the  data 
element  requirement  designators  in  the  DoD-specific  segment 
directory  section  of  the  convention.  For  ASC  X12  usage,  see  the 
definitions  in  X12.6  Application  Control  Structure. 

•  Mandatory 

Mandatory  data  elements  are  defined  by  ASC  X12. 

•  Optional 

Optional  data  elements  are  used  at  the  discretion  of  the  sending 
party  or  are  based  upon  mutual  agreement  between  trading 
partners. 
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824  Application  Advice 

This  standard  provides  the  format  and  establishes  the  data  contents  of  the 
Application  Advice  Transaction  Set  (824)  within  the  context  of  an  Electronic 
Data  Interchange  (EDI)  environment.  This  transaction  set  provides  the  ability 
to  report  the  results  of  an  application  system's  data  content  edits  of 
transaction  sets.  The  results  of  editing  transaction  sets  can  be  reported  at  the 
functional  group  and  transaction  set  level,  in  either  coded  or  free-form  format. 
It  is  designed  to  accomodate  the  business  need  of  reporting  the  acceptance, 
rejection  or  acceptance  with  change  of  any  transaction  set.  The  Application 
Advice  should  not  be  used  in  place  of  a  transaction  set  designed  as  a 
specific  response  to  another  transaction  set  (e.g..  purchase  order 
acknowledgement  sent  in  response  to  a  purchase  order). 


MQ8i  »e8.i 

2  010 

3  020 


4  030 

5  040 

6  050 

7  060 

8  070 

9  080 


Table  1 


180.10  turn _ le&eM.  iimum _ looiiicat 


ST 

BGN 

Transaction  Set  Header 

Beginning  Segment 

M 

M 

1 

1 

LOCVID.III 

2 

N1 

Name 

0 

1 

N2 

Additional  Name  Information 

0 

2 

N3 

Address  Infonnatlon 

0 

2 

N4 

Geographic  Location 

0 

1 

REF 

Reference  Numbers 

0 

12 

PER 

Administrative  Communications  Contact 

0 

3 

DA01' JANUARY  28  IMS 


Figure  1.4-1  Example  of  a  Transaction  Set  Table 
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•  Required 

Required  data  elements  are  considered  optional  under 
ASC  X12  rules,  but  are  required  by  DoD  decision. 

•  Recommended 

Recommended  data  elements  are  considered  optional  under 
ASC  X12  rules  and  by  the  DoD,  but  the  industry  recommends 
their  use  to  facilitate  EDI.  Most  companies  in  the  industry 
are  expected  to  use  this  data  element. 

•  Not  Used 

“Not  Used”  data  elements  are  those  that  the  DoD  does  not 
use. 

•  Conditional 

Conditional  data  elements  depend  on  the  presence  of  other  data 
elements  in  the  transaction  set. 
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2.0  MAINTENANCE 

This  chapter  describes  the  procedures  for  maintaining  the  DoD 
conventions.  It  also  presents  a  section  on  version/release  timing. 

2.1  MAINTALNING  CONVENTIONS 

The  DLA,  as  DoD’s  Executive  Agent  for  EDI  and  PLUS,  has 
established  a  joint  program  office  to  oversee  implementation  of 
EDI.  Some  of  the  functions  o'"  this  program  office  are  to  maintain 
configuration  control  of  related  standards  and  common  support 
packages  (e.g.,  versions  of  ASC  X12  standards  and  PLUS  algo¬ 
rithms  employed),  participate  in  the  standards-setting  process,  and 
ensure  compliance  with  approved  EDI  standards. 

To  accomplish  these  functions,  the  joint  program  office  has  estab¬ 
lished  a  conventions  and  standards  development  and  maintenance 
process  whose  objectives  are:  (1)  to  obtain  ASC  X12  data  require¬ 
ments  from  t  .e  DoD  Components  and  present  the  requirements  to 
the  ASC  X12  for  consideration  as  ANSI  standards,  and  (2)  to 
develop  and  maintain  conventions  for  use  by  DoD  Components 
and  their  potential  trading  partners. 

To  take  advantage  of,  and  not  duplicate,  existing  data  stan¬ 
dardization  processes,  the  EA  has  established  focal  points 
within  the  ASD  Offices,  the  Military  Services,  and  the  Defense 
Agencies  from  which  EDI  information  is  obtained  and  dissemi¬ 
nated. 

The  EA’s  priirary  source  of  information  about  DoD's  data  require¬ 
ments  is  the  EDI  User. 

Changes  to  this  publication  and  recommended  changes  to  ANSI 
ASC  X12  should  be  forwarded  through  your  organizational  point 
of  contact  for  data  standardization  to: 

EDI  Standards  Coordinator 
ATTN:  DLA-ZC 
Cameron  Station 
Alexandria,  VA  22304-6100 

See  Chapter  4  for  reproducible  ASC  X12  Work  Request  forms. 

2.2  VERSION/RELEASE  TIMING 

Identification  of  the  official  “version”  of  a  standard  is  critical  to 
the  successful  interchange  of  information.  Each  participant  must 
be  able  to  send  and  receive  the  same  version  to  ensure  the  accuracy 
of  the  information  exchanged. 

The  version  is  transmitted  as  a  12-character  code  in  the  Functional 
Group  Header  segment  (GS)  in  Data  Elen  ent  #480,  Ver¬ 
sion/Release/Industry  ID.  This  12-character  code  is  used  by 
ASC  X12  as  follows: 
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Position 

Content 

1-3 

Version  number 

4-5 

Release  level  of  version 

6 

Subrelease 

7-12 

DoD/Industry  or  Trade  Association  ID 

ASC  X12  assigns  the  codes  in  positions  1  through  6. 

A  major  version  (1-3)  will  change  only  after  an  official  public 
review  cycle,  leading  to  republication  of  a  new  American  National 
Standard. 

Release  level  of  each  new  major  version  (4-6)  will  begin  at  “OOC” 
and  incremented  by  1  for  each  new  ASC  X12  approved  publication 
cycle,  usually  once  a  year.  The  fifth  character  designates  the 
release  and  the  sixth  character  designates  the  subrelease. 

DoD/Industry/Trade  Association  ID  (7-12)  is  used  to  identify 
conventions.  For  thij  suffix,  DoD  will  use  “DoD_”  with  the  10th 
character  identifying  successive  publications.  The  1 1th  and  12th 
characters  may  be  used  by  the  Military  Departments  or  Defense 
Agencies. 

DoD  conventions  for  using  ASC  X12  standards  are  published 
annually.  Conventions  developed  for  each  release  will  be  main¬ 
tained  for  4  yeai'S.  Military  Services  and  DoD  Agencies  will 
determine  which  release  to  use  on  the  basij  of  business  need  but 
will  not  use  any  release  more  than  4  years  old  without  approval 
of  the  DoD  EA. 
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3.0  DoD  CONVENTIONS  FOR  USING 
ASC  X12  TRANSACTION  SETS 


This  chapter  defines  the  DoD  transaction  set  conventions.  It 
includes  the  instructions  for  implementing  the  control  structure  and 
definitions  of  the  usage  indicators  and  applicable  codes. 

3.1  INTRODUCTION 

The  power  of  the  ASC  XI 2  standard  is  in  its  building  block 
concept,  which  standardizes  the  essential  elements  of  business 
transactions.  It  is  analogous  to  a  “standard  bill  of  materials  and 
the  construction  specifications,”  which  gives  the  architect 
flexibility  in  what  can  be  designed  with  standardized  materials  and 
procedures.  The  EDI  system  designer,  like  the  architect,  uses  the 
ASC  X12  standards  to  build  business  transactions  that  are  often 
different  because  of  their  function  and  yet  utilize  the  ASC  X12 
standards.  The  “bill  of  materials  and  the  construction  specification” 
of  ASC  X12  are  the  standards  found  in  the  published  technical 
documentation. 

ASC  X12.3  -  The  Data  Element  Dictionary  specifies  the  data 
elements  used  in  the  construction  of  the  segments  that  comprise 
the  transaction  sets  developed  by  ASC  X12. 

ASC  XI  2.5  -  The  Interchange  Control  Structure  provides  the 
interchange  control  segment  (also  called  an  envelope)  of  a  header 
and  trailer  for  the  electronic  interchange  through  a  data  transmis¬ 
sion;  it  also  provide  a  structure  to  acknowledge  the  receipt  and 
processing  of  the  envelope. 

ASC  XI2.6  -  The  Application  Control  Structure  defines  the  basic 
control  structures,  syntax  rules,  and  semantics  of  EDI. 

ASC  X  12.22  -  The  Data  Segment  Directory  provides  the  defini¬ 
tions  and  specifications  of  the  segments  used  in  the  construction 
of  transaction  sets  developed  by  ASC  XI 2. 

The  DoD  convention  in  Section  3.4  conform  to  the  above  standards 
and  each  transaction  set  is  a  complete  document  to  the  extent 
possible.  For  further  clarification  of  acronyms,  abbreviations,  and 
codes,  refer  to  ASC  X12  published  technical  documentation.  Con¬ 
tact  the  DoD  EDI  Executive  Agent  for  copies  or  the  Data  Inter¬ 
change  Standards  Association,  Inc.,  Suite  355,  1800  Diagonal 
Road.  Alexandria,  VA  22314. 

3.2  CONTROL  SEGMENTS 

In  addition  to  the  communication  control  structure,  the  EDI  structure 
provides  the  standards  user  with  multiple  levels  of  control  to  ensure 
data  integrity.  It  does  so  by  using  header  and  trailer  control  segments 
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designed  to  identify  uniquely  the  start  and  end  of  the  interchange 
funcaonai  groups  and  transaction  sets.  The  relationship  of  these 
control  segments  is  shown  in  Figure  3.2-1.  Control  Segment 
specifications  are  defined  in  Section  3.2.2. 

Description  of  Use 

The  interchange  header  and  trailer  segments  surround  one  or  more 
functional  groups  or  interchange-related  control  segments  and  per¬ 
form  the  following  functions: 

•  Define  the  data  element  separators  and  data  segment  ter¬ 
minators 

•  Identify  the  sender  and  receiver 

•  Provide  control  information 

•  Allow  for  authorization  and  security  information. 

The  Interchange  Acknolwedgment  Segment  is  used  to  acknowledge 
one  interchange  header  and  trailer  envelope  where  the  envelope 
surrounds  one  or  more  functional  groups.  O^o  acknowledgment  is 
made  for  the  interchange  acknowledgment.) 

The  interchange  control  number  value  in  the  acknowledgment 
(TAl  segment)  is  the  same  as  that  for  the  ISA  segment  that  is 
being  acknowledged.  The  control  number  serves  as  a  link  between 
the  interchange  header  and  trailer  and  the  acknowledgment  of  that 
header  and  trailer. 

The  interchange  acknowledgment  does  not  report  any  status  on  the 
functional  groups  contained  in  the  interchange  and  is  separate 
from  the  communication  system’s  error  procedures. 

The  preparer  of  the  interchange  header  and  trailer  indicates  the 
level  of  acknowledgment  in  Data  Element  113,  Acknowledgment 
Requested.  If  an  acknowledgment  is  requested,  then  the  recipient 
must  return  an  acknowledgment.  If  not  requested,  none  should  be 
given. 

The  interchange  acknowledgment  control  segments  are  placed  after 
the  interchange  header  and  before  the  first  function^  group  or 
before  the  interchange  trailer  if  there  are  no  functional  groups. 

Control  segments  are  standard  for  all  implementation  conventions 
produced  for  the  Department  of  Defense.  Some  codes  associated 
with  individual  data  elements  within  the  control  segments  are 
unique  to  the  individual  transaction  set.  Others,  identify  the  ANSI 
version  and  release  in  which  the  convention  is  written. 
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Figure  3.2-1.  Hierarchical  Structure 
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Segment:  ISA  Interchange  Control  Header 

Purpose:  To  start  and  identify  an  interchange  of  one  or  more  functional  groups 
and  interchange-related  control  segments. 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

REF.  DATA 

DES. _ EkEMEMT  NAME _ ATTRMUTES _ 

iSAOl  101  Authorization  Information  Qualifier  M  ID  2/2 

Code  to  identify  the  type  of  information  in  the  Authorization  Information. 

00  No  Authorization  Information  Present  (No  Meaningful  Information  in  102) 

ISA02  102  Authorization  Information  M  AN  10/10 

Information  used  for  additional  identification  or  authorization  of  the  sender  or  the 
data  in  the  interchange.  The  type  of  information  is  set  by  the  Authorization 
Information  Qualifier. 

Implementation  Note: 

If  no  authorization  information  is  agreed  to  by  trading  partners,  fill  field  with  blanks. 

ISA03  103  Security  Information  Qualifier  M  iD  2/2 

Code  to  identify  the  type  of  information  in  the  Security  Information. 

01  Password 

ISA04  104  Security  Information  M  AN  10/10 

This  is  used  for  identifying  the  security  information  about  the  sender  or  the  data 
in  the  interchange.  The  type  of  information  is  set  by  the  Security  Information 
Qualifier. 

Implementation  Note: 

An  agreed  upon  password.  If  no  security  information  is  agreed  to  by  trading  partners,  fill  field  with  blanks. 

ISA05  105  Interchange  ID  Qualifier  M  ID  2/2 

Qualifier  to  designate  the  system/method  of  code  structure  used  to  designate  the 
sender  or  receiver  ID  element  being  qualified. 

ZZ  Mutually  Defined 
Code  Value  Implementation  Note: 

An  agreed  upon  designation  of  DoD  Activity  Address  Code  (DoDAAC)  or  other  code  coordinated 
with  the  value-added  network  (VAN). 

ISA06  106  Interchange  Sender  ID  M  ID  15/15 

Identification  code  published  by  the  sender  for  other  parties  to  use  as  the 
receiver  ID  to  route  data  to  them.  The  sender  always  codes  this  number  in  the 
sender  ID  element. 

Implementation  Note: 

DoD  activities  use  Department  of  Defense  Activity  Address  Code  ( DoDAAC )  or  other  code  coordinated  with 
the  value-added  network  (VAN).  Non-DoD  activities  itse  identification  code  qualified  by  ISA05  and 
coordinated  with  the  VAN. 

ISA07  105  Interchange  ID  Qualifier  M  iD  2/2 

Qualifier  to  designate  the  system/method  of  code  structure  used  to  designate  the 
sender  or  receiver  ID  element  being  qualified. 

ZZ  Mutually  Defined 
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Code  Value  Implementation  Note: 

Assigned  by  translation  software. 


Mandatory 


ISA16  115  Subelement  Separator  M  AN  1/1 

This  is  a  field  reserved  for  future  expansion  in  separating  data  element 
subgroups.  (In  the  interest  of  a  migration  to  international  standards,  this  should 
be  different  from  the  data  element  separator). 

Implementation  Note: 

Use  character 
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Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Segment:  GS  Functional  Group  Header 

Purpose:  To  indicate  the  beginning  of  a  functional  group  and  to  provide  control 
information 


Syntax:  The  data  interchange  control  number  (GS06)  in  this  header  must  be 
identical  to  the  same  data  element  in  the  associated  Functional  Group 
Trailer  (GE02). 

Comment:  A  functional  group  of  related  transaction  sets,  within  the  scope  of  X1 2 

standards,  consists  of  a  collection  of  similar  transaction  sets  enclosed  by 
a  functional  group  header  and  a  functional  group  trailer. 


_ Data  Element  Summary _ 

REF.  DATA 

DES. _ ELEMEWT  NAME _ ATTRWLFTES 

GS01  479  Functional  Identifier  Code  M  ID  2/2 

Code  identifying  a  group  of  application  related  Transaction  Sets. 

Implementation  Note: 

Choose  the  code  value  appropriate  to  the  i/tformation  content  of  the  functional  group.  See  X 12  Dictionary  for 
source  code  list. 

TD  Trading  Partner  Profile  (838) 

GS02  142  Application  Sender’s  Code  M  AN  2/15 

Code  identifying  party  sending  transmission.  Codes  agreed  to  by  trading 
partners. 

Implementation  Note: 

DoD  activities  use  Department  of  Defense  Activity  Address  Code  (DoDAAC).  Non-DoD  activities  use 
identification  code  assigned  by  DoD  activity.  Recommend  for  increased  security  that  non-DoD  code  differ 
from  that  used  in  ISA06. 

GS03  124  Application  Receiver’s  Code  M  AN  2/15 

Code  identifying  party  receiving  transmission.  Codes  agreed  to  by  trading 
partners. 

Implementation  Note: 

DoD  activities  use  Department  of  Defense  Activity  Address  Code  (DoDAAC).  Non-DoD  activities  use 
identification  code  assigned  by  DoD  activity.  Recommend  for  irutreased  security  that  non-DoD  code  differ 
from  that  used  in  ISA08. 

GS04  29  Group  Date  M  DT  6/6 

Date  sender  generated  a  functional  group  of  transaction  sets. 

Implementation  Note: 

Assigned  by  translation  software. 

GS05  30  Group  Time  M  TM  4/4 

Time  (HHMM)  when  the  sender  generated  a  functional  group  of  transaction  sets 
(local  time  at  sender's  bcatbn). 

Implementation  Note: 

Assigned  by  translation  software. 


Mandatory 


GS06  28  Group  Control  Number  M  NO  1/9 

Assigned  number  originated  and  maintained  by  the  sender. 


3.0.10 
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Mandatory 


Mandatory 


Implementation  Note: 

Assigned  by  translation  software. 

GS07  455  Responsible  Agency  Code  M  ID  1/2 

Code  used  in  conjunction  with  Data  Element  480  to  identify  the  issuer  of  the 
standard. 

X  Accredited  Standards  Committee  XI 2 

Code  Value  Implementation  Note: 

Indicates  that  an  ANSI  XI 2  standard  is  being  transmitted. 

GS08  480  Version/Release/Industry  ID  Coda  M  ID  1/12 

Code  indicating  the  version,  release,  subrelease  and  industry  identifier  of  the  EDI 
standard  being  used.  Positions  1  -3,  version  number;  positions  4-6,  release  and 
subrelease  level  of  version;  positions  7-1 2,  industry  or  trade  association  identifier 
(optionally  assigned  by  user). 

003020  Draft  Standards  Approved  By  ASC  XI 2  Through  June  1991. 

Code  Value  Implementation  Note: 

Code  value  agreed  to  by  trading  partners.  SeeX12  Dictionary  for  source  code  list. 
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Segment:  GE  Functional  Group  Trailer 

Purpose:  To  indicate  the  end  of  a  functional  group  and  to  provide  control 
information 


Syntax:  The  data  interchange  control  number  (GE02)  in  this  trailer  must  be 

identical  to  the  same  data  element  in  the  associated  Functional  Group 
Header  (GS06). 

Comment:  The  use  of  identical  data  interchange  control  numbers  in  the  associated 
functional  group  header  and  trailer  is  designed  to  maximize  functional 
group  integrity.  The  control  number  is  the  same  as  that  used  in  the 
corresponding  header. 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

REF.  DATA 

DES. _ ELEMENT  NAME _ ATTRULfTES 

GE01  97  Number  of  Transaction  Sets  Included  M  NO  1/6 

Total  number  of  transaction  sets  included  in  the  functional  group  or  interchange 
(transmission)  group  terminated  by  the  trailer  containing  this  data  element. 

Implementation  Note: 

Assigned  by  translation  software. 

GE02  28  Group  Control  Number  M  NO  1/9 

Assigned  number  originated  and  maintained  by  the  sender. 

Implementation  Note: 

Assigned  by  the  translation  software.  This  control  number  must  match  the  control  number  of  the  preceding 
GS06  control  number. 
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Segment:  IE  A  Interchange  Control  Trailer 

Purpose:  To  define  the  end  of  an  interchange  of  one  or  nnore  functional  groups 
and  interchange-related  control  segments. 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

REF.  DATA 

PIS.  EHMEWT  NAME _ ATtWIDUTES 

IEA01  116  Number  of  Included  Functional  Groups  M  NO  1/5 

A  count  of  the  number  of  functional  groups  included  in  a  transmission. 

Implementation  Note: 

Assigned  by  translation  software. 

IEA02  112  Interchange  Control  Number  M  NO  9/9 

This  number  uniquely  identifies  the  interchange  data  to  the  sender.  It  is  assigned 
by  the  sender.  Together  with  the  sender  ID  K  uniquely  identifies  the  interchange 
data  to  the  receiver.  It  is  suggested  that  the  sender,  receiver,  and  all  third  parties 
be  able  to  maintain  an  audit  trail  of  interchanges  using  this  number. 

Implementation  Note: 

Assigned  by  the  translation  software.  This  number  must  match  the  number  that  occurs  in  ISAJ3. 
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ST*838*C1010  N/L  THIS  IS  AN  838  CONFIRMATION  OF  REGISTRATION 

TRANSACTION  SET  WITH  A  CONTROL  NUMBER  OF 
CIOIO. 

BTP*07*CON1200*930129*0830*TP*  1 1  *  A  DUPLICATE  CONFIRMATION  WITH  A  REFERENCE 

REG(X)1*930128  N/L  NUMBER  OF  CON1200  CREATED  ON  JANUARY  29. 

1993  AT  8:30  A.M..  IT  RESPONDS  TO  THE 
REGISTRATION  WITH  A  REFERENCE  NUMBER  OF 
REGOOl  WHICH  WAS  CREATED  ON  JANUARY  28. 
1993. 

PLA*4*SE*930201  N/L  CONFIRMS  A  SUCCESSFUL  REGISTRATION  WITH 

AN  EFFECTIVE  DATE  OF  FEBRUARY  1. 1993. 

N1*ZZ**33*1B712  N/L  CONFIRMS  THE  REGISTERING  PARTY’S  CAGE 

CODEOF1B712. 

N9*VR*JCJ1221  N/L  PROVIDES  THE  VENDOR  WITH  PASSWORD 

JCJ122L 

SE*6*C1010N/L  THE  TRANSACTION  HAS  6  SEGMENTS  AND  THE 

CONTROL  NUMBER  IS  CIOIO. 


NOTE:  ALL  NUMBERS  ARE  NOTIONAL  AND  USED  FOR  ILLUSTRATION  PURPOSES  ONLY. 


BA8EUNE  AS  OF:  JANUARY  ».  IMS 


3.ai7 


DEPARTMENT  OF  DEFENSE 

DRAFT  IMPLEMENTATION  CONVENTION 


3.0.18 


BASEUNE  AS  OF:  JANUARY  29. 1993 


DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


BASEUNE  AS  OF:  JANUARY  29, 1993 


3.0.19 


DEPARTMENT  OF  DEFENSE 

DRAFT  IMPLEMENTATION  CONVENTION 


3.0.20 


BASEUNE  AS  OF:  JANUARY  29, 1993 


DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


838  •  CONFIRMATION 


ANSI  ASC  X12  VERSION/RELEASE  00302000D. 


838  Trading  Partner  Profile 

This  standard  provides  the  format  and  establishes  the  data  contents  of  the 
Trading  Partner  Profile  Transaction  Set  within  the  context  of  an  Electronic 
Data  Interchange  (EDI)  environment.  This  transaction  set  can  be  used  to 
request,  change,  verify  or  transmit  business  profile  information  to  or  from  a 
trading  partner.  This  information  can  be  used  by  the  receiver  to  facilitate  the 
processing  of  the  sender’s  business  transactions. 

The  transaction  set  may  be  used  to  convey  government  survey  information, 
business  classification,  general  survey  information,  summary  supplier 
ratings,  changes  in  the  EDI  environment  information,  tax  information,  entity 
relationships,  and  general  business  profile  informatbn  to  update  automated 
information  databases  between  trading  partners. 


PAC.£«  POS.« 


4 

010 

5 

020 

7 

030 

N/U 

040 

N/U 

050 

8 

060 

N/U 

070 

N/U 

080 

N/U 

090 

9 

100 

N/U 

110 

N/U 

120 

N/U 

130 

N/U 

140 

N/U 

150 

N/U 

160 

N/U 

170 

10 

180 

N/U 

190 

N/U 

200 

Table  1 


SEG.IO 

NAME 

REa  DES. 

MAX  USE 

LOOPRB>EAT 

ST 

Transaction  Set  Header 

M 

1 

BTP 

Beginning  Segment  For  Trading  Partner  Profile 

M 

1 

LOOPID*PtA 

PLA 

Place  or  Location 

M 

1 

LCD 

Place/Location  Description 

0 

>1 

UN 

Item  Identification 

0 

>1 

LOOP  ID- N1 

iiiliiii 

N1 

Name 

M 

1 

N2 

Additional  Name  Information 

0 

2 

N3 

Address  Information 

0 

2 

N4 

Geographic  Location 

0 

1 

N9 

Reference  Number 

0 

>1 

PER 

Administrative  Communications  Contact 

0 

>1 

CUR 

Currency 

0 

>1 

TAX 

Tax  Reference 

0 

>1 

FOB 

F.O.B.  Related  Instructions 

0 

>1 

ITD 

Terms  of  Sale/Deferred  Terms  of  Sale 

0 

>1 

TD5 

Carrier  Details  (Routing  Sequence/Transit 
Time) 

0 

>1 

FBB 

Foreign  and  Industry  Business 

0 

>1 

LOOPIO-TPO 

>1 

TPD 

Trading  Partner  Detail 

0 

1 

N9 

Reference  Number 

0 

>1 

PID 

Product/Item  Description 

0 

>1 

1 
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N/U  210 


N/U  220 
N/U  230 
N/U  240 
N/U  250 
N/U  260 
N/U  270 
N/U  280 


N/U  290 
N/U  300 
N/U  310 

N/U  320 
N/U  330 
N/U  340 
N/U  350 

N/U  360 
N/U  370 
N/U  380 

N/U  390 

N/U  400 
N/U  410 
N/U  420 
N/U  430 
N/U  440 
N/U  450 
N/U  460 
N/U  470 

N/U  480 
N/U  490 
N/U  500 
N/U  510 
N/U  520 
11  530 


DIM  Date/Time  Reference 


LOOP  ID -TUD 

>1 

TUD 

Trade  Union  Data 

O 

1 

DTM 

Date/Time  Reference 

0 

>1 

N1 

Name 

0 

1 

N2 

Additional  Name  Information 

0 

2 

N3 

Address  Information 

0 

2 

N4 

Geographic  Location 

0 

1 

PER 

Administrative  Communications  Contact 

0 

>1 

LOOP  ID -SPR 

>1 

SPR 

Supplier  Rating 

0 

1 

N9 

Reference  Number 

O 

>1 

DTM 

Date/Time  Reference 

0 

>1 

LOQPID-PAM 

>1 

PAM  Period  Amount 

0 

1 

DTM  Date/Time  Reference 

0 

>1 

TAX  Tax  Reference 

0 

>1 

CUR  Currency 

O 

>1 

LOOPID-TXN 

>1 

TXN  Transaction  Capabilities 

0 

1 

N9  Reference  Number 

0 

>1 

DTM  Date/Time  Reference 

0 

>1 

LOQPID-ENE 

>1 

ENE 

Electronic  Systems  Environment 

0 

1 

LOOPID-N1 

>1 

N1 

Name 

0 

1 

N2 

Additional  Name  Information 

0 

2 

N3 

Address  Information 

0 

2 

N4 

Geographic  Location 

o 

1 

i 

TPD 

Trading  Partner  Detail 

0 

>1 

PID 

Product/Item  Description 

0 

>1 

N9 

Reference  Number 

0 

>1 

PER 

Administrative  Communications  Contact 

0 

>1 

LOOP  ID -TXN 

>1 

TXN  Transaction  Capabilities 

0 

1 

N9  Reference  Number 

0 

>1 

DTM  Date/Time  Reference 

0 

>1 

ERI  Entity  Relationship 

0 

>1 

AMT  Monetary  Amount 

0 

>1 

SE  Transaction  Set  Trailer 

M 

1 

NOTE: 

1/170 
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With  each  occurence  of  the  PLA  loop,  the  sum  of  FBB03  for  separately  identified 
countries  cannot  exceed  100. 
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BTP  >  BEGINNING  SEGMENT  FOR  TRADING  PARTNER  PROFILE  ANSI  ASC  X12  VERSION/RELEASE  003020DOD 


Mandatory 


Segment: 
Level: 
Loop: 
Usage: 
Max  Use: 
Purpose: 
Syntax: 

Comments: 


BTP  Beginning  Segment  For  Trading  Partner  Prof  lie 

Header 


Mandatory 

1 

To  indicate  the  type  and  purpose  of  the  profile  data 

1.  C0807  —  If  BTP08  is  present,  then  BTP07  is  required. 

2.  C0908  —  If  BTP09  is  present,  then  BTP08  is  required. 

1.  BTP01  indicates  the  purpose  of  this  EDI  transmission. 

2.  BTP02  is  the  identifying  number  of  this  transaction. 

3.  BTP03  and  BTP04  are  the  transaction  set  date  and  time. 

4.  BTP06  indicates  the  status  of  the  data  content  within  the  transaction. 

5.  BTP07  indicates  reference  number  or  previous  reference  number 
associated  with  this  transaction. 

6.  BTP08  and  BTP09  are  date  and  time  associated  with  BTP07. 


Mandatory 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

REF.  DATA 

DES.  ELEIMHT  NAME _ ATTRIRUTES 


BTP01  353  Transaction  Set  Purpose  Code 

Code  identifying  purpose  of  transaction  set. 

00  Original 
01  Cancellation 
02  Add 
03  Delete 
04  Change 
07  Duplicate 


M  ID  2/2 


BTP02  127  Reference  Number  M  AN  1/30 

Reference  number  or  identification  number  as  defined  for  a  particular 
Transaction  Set,  or  as  specified  by  the  Reference  Number  Qualifier. 

Implementation  Note: 

Assigned  by  the  originator  of  the  transaction  set.  In  this  context,  assign  a  unique  reference  number  that  can 
be  cross-referenced  in  any  subsequent  transaction. 


BTP03  373  Date  M  DT  6/6 

Date  (YYMMDD). 

Implementation  Note: 

Date  the  transaction  was  created. 


Mandatory 


BTP04  337  Time  M  TM  4/6 

Time  expressed  in  24-hour  clock  time  (HHMMSS)  (Time  range;  000000  through 
235959) 

Implementation  Note: 

Time  the  transaction  was  created.  Use  HHMM. 
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ANSI  ASC  X12  VERSION/RELEASE  003020DOD 


838  •  CONFIRMATION 
N1 ' NAME 


Mandatory 


Segment:  N1  Name 
Level:  Header 
Loop:  N1  Repeat:  >1 
Usage:  Mandatory 
Max  Use:  1 


Purpose:  To  identify  a  party  by  type  of  organization,  name  and  code 

Syntax:  1.  R0203  —  At  least  one  of  N1 02  or  N1 03  is  required. 

2.  P0304  —  If  either  N1 03  or  N1 04  is  present,  then  the  other  is  required. 

Comment:  This  segment,  used  alone,  provides  the  most  efficient  method  of 

providing  organizational  identification.  To  obtain  this  efficiency  the  "ID 
Code"  (N1 04)  must  provide  a  key  to  the  table  maintained  by  the 
transaction  processing  parly. 


Mandatory 


Conditional 


Conditional 


Conditional 


_ Data  Element  Summary _ 

REF.  DATA 

DES. _ ELEMEMT  NAME _ _ ATmtEUTES 


N101  98  Entity  Identifier  Code  M  ID  2/2 

Code  identifying  an  organizational  entity  or  a  physical  location. 

Implementation  Note: 

Use  code  ZZfor  the  registering  party. 

ZZ  Mutually  Defined 


N102 

93 

Name 

Free-form  name. 

C 

AN 

1/35 

N103 

66 

Identification  Code  Qualifier 

C 

ID 

1/2 

Code  designating  the  system/method  of  code  structure  used  for  Identification 
Code  (67). 


Implementation  Note: 

Use  code  ZZ  for  a  ten^Jorary  CAGE  Code. 

33  Commercial  and  Government  Entity  (CAGE) 

ZZ  Mutually  Defined 

N104  67  Identification  Code  C  AN  2/17 

Code  identifying  a  party. 

Implementation  Note: 

N104  will  corfirm  the  CAGE  code  indicated  by  the  enrolling  entity,  provide  a  newly  assigned  CAGE  code  to 
an  enrollee  who  indicated  that  no  CAGE  code  had  been  previously  assigned  or  carry  a  temporary  CAGE 
code. 
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N9  •  REFERENCE  NUMBER 


ANSI  ASC  X12  VERSION/RELEASE  003020DOD 


Optional 


Segment:  N9  Reference  Number 
Level:  Header 
Loop:  N1 
Usage:  Optional 
Max  Use:  >1 

Purpose:  To  transmit  identifying  numbers  and  descriptive  information  as  specified 
by  the  reference  number  qualifier 

Syntax:  R0203  —  At  least  one  of  N902  or  N903  is  required. 

Implementation  Note: 

This  segment  is  REQUIRED  when  the  registrant  has  been  accepted  irao  the  program  (e.g.,  when 
PLAOl  is  code  4 ). 


Mandatory 


Conditional 


_ Data  Element  Summary _ 

RCF.  DATA 

DES. _ ELEMEKT  MAIIE _ ATTIIIEUTES 

N901  128  Reference  Number  Qualifier  M  iD  2/2 

Code  qualifying  the  Reference  Number. 

Implementation  Note: 

This  code  qualifies  the  government  assigned  password  to  be  carried  in  the  ISA04  data  element  for  all 
transactions  originating  from  registered  vendors. 

VR  Vendor  ID  Number 

N902  127  Reference  Number  C  AN  1/30 

Reference  number  or  identification  number  as  defined  for  a  particular 
Transaction  Set,  or  as  specified  by  the  Reference  Number  Qualifier. 

Implementation  Note: 

This  number  will  be  provided  by  the  Government  and  will  represent  the  government  assigned  password  to  be 
used  by  an  enrolled  company  when  submitting  a  quote. 


Not  Used 
Not  Used 
Not  Uaod 


N903 

369 

Free-form  Description 

N904 

373 

Date 

N905 

337 

Time 

C 

AN 

1/45 

0 

DT 

6/6 

O 

TM 

4/6 
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838  •  CONFIRMATION 

SE  •  TRANSACTION  SET  TRAILER  ANSI  ASC  X12  VERSION/RELEASE  003020DOD_ 


Mandatory 


Segment: 
Level: 
Loop: 
Usage; 
Max  Use: 
Purpose: 


Comment: 


SE  Transaction  Set  Trailer 
Header 


Mandatory 

1 

To  indicate  the  end  of  the  transaction  set  and  provide  the  count  of  the 
transmitted  segments  (including  the  beginning  (ST)  and  ending  (SE) 
segments). 

SE  is  the  last  segment  of  each  transaction  set. 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

RIF.  DATA 

PIS. _ ItmiKT  NAME _ ATTWMUTES 

SE01  96  Number  of  Included  Segments  M  NO  1/6 

Total  number  of  segments  included  in  a  transaction  set  including  ST  and  SE 
segments. 

SE02  329  Transaction  Set  Control  Number  M  AN  4/9 

Identifying  control  number  assigned  by  the  originator  for  a  transaction  set. 

Implementation  Note: 

This  is  the  same  number  as  the  one  in  ^02. 
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nSOBA  SPORMATON  MANUAL 


VIII  -  FORMS,  FORMS,  FORMS 


ASC  X12  Wofk  RsgusM  Fonn 

ASC  X12  Nsw  Prettei  Pfoposal  Fonn 

ASC  X12  Now  Tnnsaeilon  Sot  Oovoiopmont  Fonn 

Fonn  for  Now  or  Roviiod  Aopondbc  A  Codo  Soufco  Rotofoneo 

OoouRiofli  ProporMion  lor  irooiprotMions.  Quidolinot  and  Coflttol  Standards 

Sompia  Tranamnal  Form 

ASC  X12  Bolot  Commant  Rosponoo  Lottor  Format 
ASC  X12  Standards  Ordar  Fonn 


FALLiasa 


vni-i 


SASEUNE  AS  OF:  JANUARY  20, 1903 


4J).3 


Am.  S/10/90  dm  number _ 

DATE  SUBMITTED  (S#erttarl«  Only) 

- ASCX12 

WORK  REQUEST  FORM 

ALL  REQUESTS  MUST  BE  TYPED  or  prMad  lagibly  in  bUcfc  Me.  ComplAtt  both  %idS. 

1.  TOUSErMSraAMroASUPAOATMQOATAMMNrENANCEroAANEWOAAFrSTANOAnOORX12MTEAPAETATlON.IM«i 
raquirMiwmenONEtonn.  Um  MacArnMNi  m  rtMMMfy.  LM  Aral  •>  am  aagmana.  «ma  ai  mw  dait  atamanti/oodM/eoda  MgroM. 
Thaa  lai  tawtatona  aa  aaMAS  aagmama  and  data  aiamama/eodaa/eada  aouioaa.  Than  Hal  any  odwn  fa-g..  X12.S.  XlZt). 

2.  TOUSCTHttFOAMTOREQUESTACHANQETOANeaSTMQSTANOAAO.uaaaaaparalaWMiAaq«iaalFefmtoHaiaHenMgaa«or 
ana  wnaaedan  aai.  ana  aagmam,  ana  eonaol  atwidyta.  or  ana  daia  alawant  Al  aaedona  muai  ba  eampMad.  AitaclMwanta  may  ba  yaad 
far  aondiHiaiian  and  ahoutd  ba  numbaaad. 


3.  TOUSETHSFOAMTOAEQUESTAPAOPOS8)fCWXl2mOJECr.aamaiaiaSaedanA.  ArowMa  a  purpoaa/aeepa  Mid  daaedba  Miy 
naw  laaiuraa  inwolMd  in  Saedan  8.  Aroalda  a  daaetipHan  of  dia  buainaaa  naad  and  juaHHeadan  far  dia  naar  pw|aci  In  Sacdon  C/Pan  X  Ttia 
^Mard  Raquaai  «id  ba  fanrardad  fa  an  agprapnaia  X12  tUbQOMfflittM  lOf  EMlyiM  Md  pftpRfMlOfl  Ot  ft  pfOfSCl  pfOpOMl. 

CketoOnt:  (1)  New  Slandaid  Supporting  Data  Mainign8net(uMaiiadvn«nls) 

Existing  Standard  MaMananca  Raquaat  (saa  Sestlon  D) 

0)  RaquastfdrNawX12Proiact 

Aeranywa/anbrai  fadawa  cannei  ba  addad  fa  dia  aiandarda.  Induaby  apaeWe  farma  maai  ba  alaaify  aiplabiad.  AraaldaAppandbiAaada 
aaurearafatanoaafaraSartamadypiibliatiadaadadaiaaaad.  bieamplaia  fanna  ar  twaa  nm  madaquaia  aappon  for  fia  ananga  raquaaiad 
add  ba  raiuinad  fa  dia  aubrnmar. 

A.  iUBMlHibNINf-UHMAIIUN 

Submiltan  Nama 

Company  _ 

Addrass  _ 

Addrass/ZIP _ 

Phona  _ 


Indicatatha  XI 2  subcommStaa  or  taafc  group  whoaa  position  Is  raprasantadhara. 

I  dadarattiat  this  rapraaanlsthaoflleial  position  of  X12  WORK  GROUP: _ 

astabliahad  at  tiM  maaUng  datad _ 

B.  PROPOSED  WORK:  List  ttw  spacMc  changas  to  tha  standards  baing  raquastad.  GNa  ttia  namas  and 
assodatad  Uentnars  of  tha  standards,  sagmants,  data  alamanu  and  codas  aflactad. 


4A.4 


BASEUNE  AS  OP:  JANUARY  2S,  ISSS 


OCTAimMNTOF  OBFOWe 
OfUFT  MPLEIIBNTATION  CONMMTION 


Pag*  Two 

t.  REASON  FOR  CHANGE: 

Paitl:  Ust  th*  v*raion/r*l«aa*  of  th*  atandaid  you  ar*  using  or  using  as  a  rifaranc*.  Nam*  tha  tranaacUen  sat 
that  la  baing/wW  b*  usad  that  dictatas  tha  raquastad  ehangad.  List  affactad  sagmsnu  and  data  atamants.  or 
othar  standards.  Provid*  only  rafaranc*  numbars/IOs. 

Rafaranea  Soure*  Varalon  2/Ral**a* _ 

Transaction  Sat  Usad 

Sagmant  Affactad  _ 

Data  Elamant  Affactad 

Othar  Standard _ 

Partll:  Explain  why  you  naad  tha  proposed  changa.  Prould*  a  complat*  seanarto  that  tals  what  tha  businass 
function,  oparation.  or  problam  is  that  wEbasatlsfiad  by  a  Chang*  to  tha  standard.  Tha  Xt2J  Tachnieal 
Assaasmant  Subconuniitaa  raquiras  anough  Information  in  this  Part  II  to  b*  abi*  to  propoaa  an  aftamata  solution  tf 

nacassary. 


67  RAMIFICATIONS:  Nyoudrclad  (2)onPag*i.compiat*thissactloa  To  anaura  that  al  ramllcailons  of  your 
propoaad  changa  ar*  rscordad  and  that  your  raquast  Is  complai*,  circl*  baiow  al  sacdono  of  Ih*  standards 
affactad  by  tha  propoaad  changa. 


transaction  SET  Nwiw  A«pow/9aoa«  TaM*  Now/Cammam 


SEGMENT 


DATA  ELEMENT 

CODE 


ayrnwiNM  SMiwnScNM 


NWfw  Dwotipaow  Tyaa 

Mn/Mai 

MdaoSi  OtlMiCoaa  AwWaCod* 


OTHER  (*.g..Xl2.S,X1&e): 

ERRORS  NOTED  IN  THE  STANDARD  (QN*  paga  na  and  othar  IdantllcMiQn): 


■ASEUNE  AS  OF:  JANUARY  at,  ItM 


4.0.S 


DOARTUBITOP  nrouf 

ONAFT  MPLEMfHTATION  CONVEMTION 


R*w.  4/1/90 


PP  No. _ 

(Stcratarlat  Only) 


ASC  X12 

NEW  PROJECT  PROPOSAL  FORM 

PROCEDURE:  Only  X12  subcommittaes  may  um  this  fonn  to  register  new  development  actMtles  as  X12  project 
proposals  (PPs).  Cimpiata  aH  pagas.  PPs  approvad  by  tha  X12  Procaduras  Raviaw  Board  wil  ba  ragistarad  and 
assignad  a  PP  numbar  by  OISA.  and  a  Transrnittal  Form  wfli  be  issuad. 

Data  and  complata  tha  form  balow.  Typa  or  print  lagibiy  in  black  Ink  and  numbar  all  attachment  pagas 
consecutively.  Submit  to  DISA  prior  to  an  ASC  X12  meeting,  or  to  X12J  Technical  Assessment  Subcommittee 
during  the  subcommittee's  agerida  period  at  an  ASC  X12  meeting. 


Date  Submitted: 

Date  Approved  by  Subeonunittee: 

Subcommittee  Name:, 

Task  Group  Name/No.: 

Joint  Development  Subcommittee  (H  any): 

Circle  one:  (a)  Transaction  Sat  (b)  Guideline  (c)  Other 

Project  Working  Title: 


Official  Oaiegate(s)  for  This  Prcject  To  Be  Named  on  Tranamlttal  Form: 
Name  _ ^Name _ 


Company _ ^Company 

Address _ ^Address 


Address/ZlP _ ^Addrass/ZlP 

Telephone _ _ Talaphone 


4.0.6 


BASEUNE  AS  OF:  JANUARY  29, 1993 


proposed  work.  SooXiSOosIgnRUMSitdGuldsUnMtorroquirsnwntt. 


B.  ^tKdRdUNO:  ^rowWo  docils  IM  wfl  be  hilpM  ki  rovtMvino  Iho  propoMl.  WhoarothonpKMdusirs? 
HowwBtho«andardboutod?  Wtw  businosc  funetlor)(s)  doM  k  servo?.  If  the  proposed  nndardrNoilape  the 
funcdonsllty  of  an  eidsdng  standard  or  one  In  devstopmetk.  prcMtde  justWcMlorv  If  Ota  proposal  Is  not  for  a  new 
standard  or  puldsHna.  deacribs  ths  projact  m  detal  (1^  attachments  i  naeaaaary.) 


C.  otMEH  BTAWdAWbi  lliVOI.VEO;  If  appfcaWe.  Identfy  any  Other  buslnaaalnlonnatfen  standards  that  are 
simlar/rsiatad  to  the  proposal,  and  name  standards  davalopars  (s-Q..  ANSI  AccredMd  Standards  Convnttoes) 
whose  actMUsa  may  ba  Involved  or  aHacMd. 


0.  EXPECTED  CONTBNT/OENEfUL  DCBCfWnON:  (OFnONAL)  Submttar  rnay  OBach  a  preliminary  draft  of 
ths  proposed  standard  or  oihsr  supporting  documantadon.  DIscuaa  new  segmena.  data  alatnanta.  coieiol 
structures,  and  changas  to  X124  or  X116  that  are  required  or  andclpaisd.  (Use  attachments.) 
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FORM  FOR  NEW  OR  REVISED 
APPENDIX  A  CODE  SOURCE  REFERENCE 

INSTRUCTIONS:  Complete  this  form  whenever  a  new  data  element  or  data  dement  cod«  is  raquestad  to  bt 
added  which  references  a  code  list  published  by  an  extemai  (non-Xi2)  organization.  Use  one  form  for  each  new 
reference.  This  form  may  be  used  to  revise  current  references;  fill  out  the  appropriate  areas  below. 


CIRCLE  ONE,  COMPLETE  AS  APPROPRIATE: 

(1)  NEW  REFERENCE 

(2)  REVISED  REFERENCE,  Current  reference  number/name _ ^ _ 

REFERENCE  TITLE:  If  there  is  only  one  source  for  codes  for  the  data  element  the  title  should  be  the  same  as  the 
data  element  name.  If  there  are  multipl*  codes  referencing  extemai  code  sources  for  the  same  data  elemant.  tMe 
should  approximate  the  code  definitioa 

REFERENCE  TITLE: 

DATA  ELEMENTS  USED  IN:  Give  the  dau  element  reference  number  and  name  which  directs  the  user  to  this 
Appendbt  A  code  source  reference.  Qlve  the  code  ID  (V  assigned)  If  this  is  for  a  specific  code  of  the  data  elemenL 

USED  IN;  DE  No. _ .  Code  ID _ 

SOURCE;  Provide  the  name  of  the  publicattow  which  contains  the  codw  referenced. 

PUBUSHED  IN; 

AVAILABLE  FROM:  Give  the  publisher,  or  other  contacL  from  whom  the  user  can  obtain  the  donsnere. 

Name/Attn  of  _ 

Company  _ 

Address  _ 

Address  _ 

Address/ZIP  _ 

ABSTRACT:  Briefly  describe  the  publication,  its  purpose,  and  indicate  what  codes  It  contains. 

ABSTRACT: 


4A.S 


BASELME  AS  Of:  JANUARY  2S,  1SS3 


OEPARTIIENTOF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


DOCUMENT  PREPARATION  FOR 
INTERPRETATIONS,  GUIDELINES  AND  CONTROL  STANDARDS 


Rm.  4/1/90 


Thtt«  instructions  art  providtd  to  assist  davalopaa  at  Intarpratations.  guidalinos  and  control  structura  which  art 
not  transaction  sats  (for  transaction  sats  usa  tha  Now  Transaction  Sat  Davaiopmant  Form). 

GENERAL  OISA  prowidat  tMa  poga  and  front  mattar  for  publications  and  copyadlts  tha  documani  according  to 
DISA  house  styla. 

REVISIONS:  If  tha  documant  is  a  revision  of  a  praviousty  pubiishad  irtarpratation,  guidallna  or  staridard,  provida  a 
summary  of  tha  changes  to  tha  original  that  are  contairtad  In  tha  documar*. 

I  INTERPRETATIONS 

A  formal  Imorprotation  of  an  X12^  Standard  Is  considarad  part  of  tha  body  of  standards  whan  k  is  approved  for 
publication.  Tha  intarpraittion  draft  ahotid  state  tha  issue  prasantad  by  tha  raquastor.  state  tha  propoaad 
Marpratation.  and  show  as  attachments  any  Work  Requests  that  may  be  naeeaaary  to  affect  tha  Marpralatlon 
within  tha  subfact  standard.  Tha  draft  Morpratation  ia  procasaad  Uka  any  other  subcommttaa  documart. 

tt  QUIDEUNES 

For  publication  purpoaas.guidallnes  are  traatad  lira  a  journal  artlda.  Basic  raqukamoras  ara  givan  below. 

ABSTRACT:  ThisiaaprociaasunMnaryofthoPurpoaa/Scopa(saabaiow),andmaybaidantlcMtokVthatlsbr1af 
(two  paragraphs);  otharwisaaummariia  tha  purpoaa/seopa.  tt  shoiid  contain  enough  Mormadon  abou  tha 
docutnant  to  anabia  a  raadar  datannina  what  tha  gukMtna  is  kiiendad  to  accornpiwi  wtthin  an  EDI  anvkonmant 

PURPOSE  AND  SCOPE:  This  atatamsra  must  indIcats  purpose  of  tha  guidaHna.  a.g..  lha  businaaa  function  or 
oparationaddrasaad.  Scopa  and  any  apadic  imkations  of  scopa  shotkd  ba  dafinad. 

BODY  OP  TEXT:  This  may  be  a  numbar  of  subsactiena  logically  organized.  Providasactlona  for  foreword. 
Introduction,  definition  of  terms  and  concepts,  rafarancas  and  ralatad  standards,  methodology.  spadBcationa. 
raquiramants.  discussion,  and  conclusions,  as  appropriate  to  the  subject 

ART  AND  GRAPHICS:  Graphics  or  artwork  nacassary  to  flustrata  the  documarft  ara  encouraged.  Provida 
camara-raady  copy  if  these  ara  not  akaady  praparad  and  daiivarad  on  a  WP  diskoita  to  DISA. 

FOREWORD,  FOOTNOTES,  APPENDICES:  Thesa  may  ba  used  for  purposes  of  darky,  Buatratiort,  or  ganard 
informailon.noias*partofihaguidallna.'  A  atatamartt  MIcating  tha  niatsrial  Is  for  Monnation  purposes  only  and 
not  part  of  tha  guidaNna  shaft  appear  at  the  beginning  of  a  foreword  or  appandbe. 

Ill  CONTROL  STRUCTURES  AND  OTHER  STANDARDS 

For  publication  purposes,  these  documantt  ara  traatad  like  guidalinas  (see  Section  II  above).  Tha  raquiramanu  ara 
the  same,  with  tha  addttion  of  the  foftowlng: 

NEW  SEGMENTS  AND  DATA  ELEMENTS:  Thesa  may  ba  dsAnad  wkhin  tha  taat;  howawar.  ainca  they  raprasarft 

changes  to  X12.22  and  X12.3,  they  should  ba  spacMad  on  a  Work  Request  Form  attached  to  the  draft 
RELATED  XlftTM  STANDARDS  AND  OTHER  REFERENCES:  These  shaft  be  idantiflad  bi  a  section  wkhM  tha  text 


BA8EUNE  AS  OF:  JANUARY  29, 1993 
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FOAMAT:  *Thto  OraK  Standard  for  TfW  Um  coniainc  ih«  fonrwt  and  MtibUtftM  ttw  dati  oonianu  of  ttw 

_ Tranaaedon  Sal  (  )  for  uaa  wtNn  itw  comaid  of  an  Bactronic  Data  Irtarcdanga  (EIX) 

anwifonmant  Tha  tranaaedon  aat  (can  ba  uaad  ta..)* 


C.  PURPOSE  AND  SCOPE  ThN  Natamant  muat  Indlcata  tha  Ml  ranga  Of  capafaHHaa  of  ttia  tranaaedon  aat  and 
whotttaaandara/raealwaraara.  Eidtein  tha  buainaafi  function  or  oparadon  that  la  addraaaad.  FolowASCXt2 
Oa^  RtJaa  and  GuidaNnaa  and  uaa  tNa  format: 

FORMAT:  Thia  atandaid  prwAdaa  tha  format  and  aalahHahaa  tha  data  eoniaraa  of  tha _ T'anaactlon 

Sat  wtMn  tha  contaxt  of  an  Bactronic  Data  lniarehanoa^)anwironmanL  TMa  tranaaedon  aat  (can  ba  uaad  to...)' 


D.  TRANSACTION  SET  TAiLl(S)  For  aach  taOfa  pro<rtda  tha  WtoMno  Inloniiadon.  FORMAT: 

TABLE  X 

POSITION  SEGMENT  REQ.  MAX.  LOOP  REPEAT  NOTE 

NO.  ID  TITLE _ PES.  USE. _ fifiOO _ 

010  ST  TranMctlon  S«t  Maaddr  M  1  Nota  1 

020  BB  Bagiimlng  Sa^aant  For  M  1  coaaant  l 

ate. 

Natal:  TNaiaanoia.  NOTES  am  part  of  ttiaatandard(nuriibarad). 

CommaraA:  Thia  la  a  oommarc  COMMENTS  art  not  pan  of  tha  atandard  gadarad). 


rTr-r*  iv' 


UMfl.  M  MS  OM  m  IMnOMOfy*  HO  pi^pir  rWnHm  VfWy  W  UNO  VI  ony  NOiiMO* 


FIGURE  1:  (Optional)  Uaa  a  aampfapapardoownartuaing  mock  data.  V  uaad.  data  muat  bo  aoeuraiNymappad 
toFigwaS.  Orl9lnalgraphlcarmtbaaBachad(S-i/2xii*)aothavcanbacopiad. 

FIQURS  a  (or  EXAMPLE):  THaSiaflsuraandprowldaaBualnaoaSeanaftoioai^Wntothaiaadarwhotlagolng 
oninthaoKompla  Addttwnoia:  TntMaawam^athaaaMrtafcOrapraaantathadataalamantaapaiatorandtha 
N/L  charactara  rapraaara  tha  aagmara  tarmlnator.*  Fraaani  EDI  tranamlaalon  data  and  ta  moaning  m  twro  columna, 
aid»Oy-aida.  ZZerZBeodaaara<f>ioouragad.Nneathairuaafilnaaalnan«0anaioryManpialanl.  FORMAT: 


BUSINESS  SCENARIO:  In  thta  tranaaedon  aat  tha  aandar  la  XY7  Ratal  Caraar  and  tha  racaNar  la  thalrauppllar. 
Faniaade  Froducia  Mamdacturlng.  lnc...ott. 

EDI  TRANSMISSION  DATA _ (TRlWSf^ON  SET  PURPOagLaM^L 

ST*SXX*000S  N/L  BoGin  Trandaction  Sat  txx;  Control 

No.  0005 

BB*01*79S00*  N/L  Original  Tranaaiaaion;  Raf.  No. 

79S00 

ate. 
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DMNumby 

(SAcrittrMt  Only) 

DocumATtNo. _ 

(Dtv«lop«r  ObtAlnt  from  OISA) 


ASC  X12 

NEW  TRANSACTION  SET  DEVELOPMENT  FORM 

INSTRUCTIONS:  Um  this  form  to  submit  •  draft  transaction  sat  for  rtviow  by  X12J  Tochnicai  AMMsmonTund  li  it 
text  processed  by  DISA.  Use  e  new  Transaction  Set  Development  Fonn  whenever  ravlaions  are  proposed  and  a 
text  file  has  not  y«  been  prepared  by  OISA. 

ATTACHMENTS:  Anach  al  pages;  use  this  form  as  the  flrsL  FoRow  these  Instructions  for  preparing  materfais. 

The  submkter  must  obtain  a  document  number  assignment  from  DISA.  Poet  It  to  this  fonn  (above). 

Attach  a  List  of  Revisions  If  the  draft  was  previously  reviewed  by  XI 2J  or  I  this  Is  '  rsvtsed/radesigned 
transaction  set  standard  requiring  X12  beloL 

Use  ONE  Work  Request  Perm  to  list  all  supporting  data  mairaononca  for  the  transaction  set  and  attach  I 
tothisform.  Propose  new  or  revised  codes  fwDE  143  and  DE  479  eta  minirrum  Knquind. 

A  Transmittal  Form  must  accompany  this  document  when  R  is  submiitsd  to  DISA  for  distrtMition 

Use  the  most  recent  X12^  Standards  Development  Workbook  to  cheek  your  document  lor  accuracy. 

A.  SUBMI I  IbR  INFORMATION 

Submitter  Name 

Company  _ 

Address  _ 

Address/ZIP  _ 

Phone  _ 

Indicate  the  Xt2  subcommittee  or  task  group  whose  position  Is  represented  here. 

I  declare  that  this  represents  the  official  position  of  X12  WORK  GROUP: _ 

established  at  the  meeting  datsd _ . 


B.  ABSTRACT  The  Abstract  Is  registered  wkh  the  American  National  Standards  Instituio.  It  is  a  precise  summary 
of  the  Purpose/Scope  (see  Section  C  beiow).  It  may  be  identical  to  the  Purpoee/Scope  i  that  Is  brief  (two 
paragraphs),  otherwise  summarize  the  purpoee/scope.  It  should  corkaln  ertough  Mormation  about  the  standard 
to  enable  a  potentiai  user  determirte  what  equivaiera  paper  transaction  It  represents  or  whet  the  standard  Is 
intended  to  do.  Follow  the  format  on  page  two. 
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SAMPLE  TRANSMITTAL  FORM 


Rm.  S/10/90 


MUaUxad 

KEY  DATE:  Ftbriiwy  18,  ItM 

DELEGATE'S  NAME 
RESPONSIBLE  SUBCOMMITTEE/TG# 

TRANSACTION  SET/GUIOEUNE  TITlf 

BALLOT  Document  No. 

Current  Document  No. 

Previous  Document  No. 

Project  Propose!  No. 

Associsted  WR/DM  No. 


John  Doe 

ASC  X12Q  XX  Subcomm)nee/TG4 
XIZOX  ABC/XYZ  TRANSACTION  SET  (8XX) 


A5CX120/9(M)51 
ASC  X12Q/9(KX>4 
PP-fiSB 
DM  012-190 


PROJECT  PROPOSAL 

PP  Review  by  X12J  PATE)  2/7/90 

PRB  Approves  PP  PATE)  2/9/90 


DEVELOPMENT  PHASE:  Project  proposal  approval  through  approval  for  X12  vote. 


Document  Submtted  for  DISA  Taxi  Procesaing  PATE) 

Subcommnee  Approves  Draft  for  Review  by  X12J,  Tech  Asaessmoft  PATE) 

X12J  Tech  Asaassmera  Review  PATE) 

PRB  Approves  Document  for  XI 2  Vote  PATE) 


ORIGINAL  BALLOT  DATA  piSA): 


Batot  Closed  Date  PATE) 

TaBy/CommentsSenttoChalr/Delegates  PATE) 

TaVy  Statt  (Number  and  Percent) 

_ Balou  Mated  (100») 

_ BafloU  Returned  ( _ %) 

_ Approved  ( _ ^%) 

_ Appw/Comment  ( _ ^%) 

_ Disapproved  ( _ %) 

_ Absuined  ( _ %) 


4a.ia 


BA8EUNE  AS  OP;  JANUARY  a.  ISSS 


<» 


DEPARTMENT  OF  DEFENSE 

DRAFT  IMPLEMENTATION  CONVENTION 


DEPARTMBIT  Of  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


PsgtTwo 

COMMENT  RESOUmON  PHASE:  Sm  S«ctiont  A.  B  and  C.  If  Dm  tubcommlRM  at  any  tirn*  d«ddM  to  rtbsM 
th»  documanL  PRB  approwil  M  raquirad  and  rasponM  Mian  ara  not  nacasaary. 

A.  COMMENT  RESPONSE  LETTERS:  An  Opan  Forum  muM  ba  schadUad  at  tha  naxt  X12  maating  foBowing  tha 
tMiot  doting  data.  AB  thoaa  vvtw  commaraad  racatwa  a  commant  ratponsa  lattar  from  tha  davaloping 
aubcommttaa.  DISA  raeorda  thM  procau  and  handMt  tha  mating. 


Opan  Forum  Data  (DATE) 

Ratponsa  Lattart  Malad  Out  by  DISA  (DATE) 

RabuRai  Pariod  (30  dayt)  Ctoaaa  (DATE) 


ADJUSTED  BALLOT  DATA  (DISA): 

30-Day  Ratponta  Ravlaw  Ckiaad  Data  (DATE) 

TaBy/Comrnanta  Sara  to  Chalr/Dalagatat  (DATE) 


TaBy  Stata  (Numbar  and  Parcart) 

_ BMottMaBad  (100%) 

_ BaBottRaiumad  ( _ ^%) 

_ Approvad  ( _ ^%) 

Aoow/Commani  (  %) 

_ DMappravad  ( _ ^%) 

_ Abatainad  ( _ %) 


B.  SUBSTANTIVE  REVISION:  N  boBol  commarSa  raadt  In  aubatanilva  raviaiona  to  tha  documani.  thaaa  ara 
laviawadbyXiEJandprooaaaadbyOISA  TharavlaaddocwnaraiaaubmUadtoXlEvoiorsloraSO-dayrovlaw 
pariod.  DISA  racorda  thla  procaaa/hancBoa  mating.  SubcommBtaaaahoiBd  conduct  30-day  ravMwa  tor  raaponaa 
lattars/raviaad  documanto  concurmiaiy. 


Subcommittaa  Approval  of  RavWono  (DATE) 

X12J  Raviaw  of  Raviatona  (DATE) 

DISA  Mata  Ravlaad  Documant  (DATE) 

Subatantlva  Raviaion  30-Day  Raviaw  Ctoaaa  (DATE) 


ADJUSTED  BALLOT  DATA  (DISA): 

30-Oay  Subatantlva  Changa  Raviaw  Ctoaad  Data  (DATE) 

TaBy/Commanta  Sant  to  Chak/Dalaoataa  (DATE) 


Taly  Stats  (Numbar  and  Parcani) 

_ Ballou  Matad  (100%) 

_ BaBoURaiumad  (  %) 

_ Approvad  ( _ ^%) 

_ Appw/Commara  (  %) 

_ Disapprovad  (  %) 

_ Abaulnad  ( _ ^%) 
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PagcThrM 

C.  CONTINUING  OBJECTIONS.  If  thcr*  ar«  continuing  disapprovals  after  the  30^y  review  period,  th« 
document/disapprovals/responses/continuing  objections  are  maled  to  X12  members  who  originally  cast  a  ballot, 
for  another  30-day  review,  to  give  them  an  opportunity  to  change  their  vote. 

Continuing  Objectiorw  Maled  to  Chair/Deiegate  by  DISA  PATE) _ 

DISA  Male  Documentt  PATE) _ 

30-Oay  Review  Cloaes  PATE) _ 


FINAL  ADJUSTED  TALLY  piSA):  Whenever  any  disapprovals  are  withdrawn,  a  letter  to  this  effect  must  be 
received  in  writing  by  DISA. 

Rnal  Tally  Results  Sent  to  Chair/Oelegate  PATE) _ 

30-Day  Review  Stats  (Adjusted  TaRy) 

_ Ballou  Maled  (100%) 

_ Ballou  Returned  ( _ %) 

_ Approved  ( _ %) 

_ Appw/Comment  ( _ %) 

_ Disapproved  ( _ ^%) 

_ Abstained  ( _ %) 


PRB  APPROVAL  PHASE:  After  the  comment  resolution  period,  the  subcommttee  votes  to  submit  the  document 
to  the  PRB  for  approval  to  publish. 

Subcommittee  Votes  to  Release  to  PRB  PATE) _ 

PRB  Approves  Publication  (DATE) _ 

FOR  DRAFT  STANDARDS  FOR  TRIAL  USE: 

VERSION/RELEASE/SUBRELEASE  ID  CODE  ASSIGNED: _ 
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TRANSMITTAL  FORM  INSTRUCnONS: 

GENERAL:  This  TranamttN  Form  la  a  TURNAROUND  DOCUMENT  whictiraeordsthahiNory/eurrantatatua  of  a 
profact  documaiK.  It  la  uaad  to  aacchanga  Irionnatlon  barwaan  tha  Sacratariat  and  tha  commMaaa  ct  X12. 
Irdonnation  la  cumiiatNa  (add  on).  Thia  form  la  attachad  to  tha  doeumant  aRwnaMor  K  la  laauad  tor  diatrlbutlon  (I  la 
mandatory  tor  aubmMIng  documanta  to  PISA.  X12J  Tachnical  Aaaaaamart.  and  tha  PR8).  Docunant  control 
numbara  ara  atl  raquirod  on  aach  doeumart.  and  nwr  nuRtoara  ara  raqulrad  atoanoMor  lla  ra^aad. 

KEYOATE:  TNa  la  uaad  to  idaraMy  tha  laiaaivaralon  of  tha  documant  (data  aaaodatadwth  tha  currant  tranamttal 
form  update). 

DELEGATE:  Each  aubcommiBaadaaignataa  an  lndMduai(dalagata)  from  tha  group  raaponatito  tor  tha  projacL 
Tha  Sacratariat  muat  b*  totormad  V  tha  dalagato  changaa. 

INfTIATION:  Primary  data  la  racordad  by  DISA  on  tha  MHaltzad  form  altar  th*prQ|*ctprQpoaal  la  approwad  by  tha 
PRB.  Tha  auboommatoa  chair  and  dalagata(a)toca»m  tha  IntlaaiadTianamMal  Form  bom  PtSA;ihafaaltaf.  they 
araraaponatola  for  racording  tha  appropriataaubcommittaa  approval  data*.  Tha  chalr/daiagaia  wl  racaha  a  copy 
of  tha  updated  tranamBal  form  aihanavartlirpifaad  by  PfSA. 

UPDATING:  At  each  approprlai*aiap,Dl$A«iM  POST  Iraah  data  to  the  form,  ADO  die  naad  appropriate  blanka  to 
tha  form,  and  SEND  I  to  tha  aubcommataachalr/dalagata  at  each  atatua  change.  Tha  dalagMa  muat  POST  tha 
form  aRhbaah  data  at  each  atatua  change  tor  a>hlch  tha  aubcommitta*  la  raapcnatol*  and  SEND  I  wMhbia 
appropriato  documant  to  tha  Sacrotariat 
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ASC  XI 2  BALLOT  COMMENT 
RESPONSE  LETTER  FORMAT 


OaiOUL  MPOmiATION 

APm  AN  IIS  •AUOT,  iMt  RaPONHIU  tMCOyMmE  (Oil  rn  OtMNATtD  TAM  OHOUP)  MIMT  iMpMd  In  10 

dNaNmal^om.  TtMnrpiniirtnn  I  rmwrtim  iwnuN  riTMH— ttitimitOT  nnirtniiirirtlBnunnnrtin  Sum  rrnmiwn  wtw 
■S»i»wawt>OBiniw>m.buiM— *y  — — wipcndua.  1>«OPMtMMlwiiaeo)Mnani«Mp«wMiiiiMb»aeen*iaid 
««i  «•  SutaanwttM  Ch*. 


r«McN«Oh» 


OPnONi:  OBICMeiJETTIRillAiTllllCrTBqTOAUeOMIBITOM 
viiMiimrpwiiniowlNTaMtiinIcowiwnm.  Enwy  cpwiiMm 

Nmm*  Ms  opian,  y«u  group  #• 


OPnaK&  MMVIOUALUTTBITOIAeNOOMIBnOR 

Vm  mar  prapsiooM  Mar  tar  Spoil  eammsnigr.  MyauslioaiaMsapMn.|OunaorioaimpaaitiaarigMaammompmidMantitMMt 
PoSmt  tap  uwMtaisltmsstaMriirta  Pita  tip  gstiartalnsmiaionsSalasr.  imtymswpartapl  NspppW'ippmuslMisipondMta. 


MTIIUCnONi 

•TIPI:  Ptantap(MPiofcsipa|a**MVlMtai(i)anAICX1StaHrtMaA  I  you  Mm  haw*  taaMmod,  you  pm  Main  soma  tom  Pm 
•owMMormpisMosPtaspmptaiPpiAail.  Vpu  map  nat<mopMBaMl,smpoitaP,«  tank  taMrtMpp  tar  yowoommsi«mapanaatataH(t). 

•TIPt:  CalffmlaomtartaitaraMaumanioontsimBitaar.  TlitawpitaPrmiMapppmlw»PMparP|litopwprpHistasipppp«ltmtaMr. 
■yPHMiidpninMMMlioPMtartappMpnmmmMr.piaMawipHteoitaolmmtasrMilgnsPtartaPttittaMrpNtPtaMppPtysWA* 
(p«.  ASC  XISPnatafO-iaOA).  sasonP  tar  a  *r  (P-t^  ASC  XtSWTOtaMiaW).  PM 

•TIPS:  *^rTTi  irmr ‘ITT  tnnnit  iipliri  (iw  linorg  titamptuu  Nisii) 

•TIP4:  *~r — “nY- itiiro  1  npinta Itiisinsii Xlir tiiTTM 

P-  PissiMaoontagnpmp(iiwMri)tafiPuppmtip|psowirtaBoHiPlpamiPPd;inataMphonpnumtsr. 
b.  Prim  ffwMeumamaonMnumbarunMr  Pip  IsMrtiaaP  boa. 
e.  PitwpipMtauiiMrPiiPBCHmpmopwpslPumbpr. 

A  AdtaassP«taMraPtainMMMI.artaragsnsMisMrtaitaMvtadSsaooplnpaiirisutaMllnp. 

0-  bMtaMpnbitsPMtafyparapiMliMpiPtaMiaitpmpoilrUsnSPsPtaPmaPPisssPo. 

I.  YoMmpystabtaiPcopPmbNMtata  (tomyoirTriiipiisMPorm)larPiplntaimMpnp(PipmpMr. 

•TIP  4:  Poi«afdPiPtaHfs»PipSacistaitai,AMn4onSaas«riaiaarvtaas.«MaopwrtaMrisqusaPn|SBttauPsiiplPamtp«wp 
taMUt)  you  hmrn  prspatiA  PllianPiataMrsha<mbapntft«tautaP.Pmim|MPmiga»an4suboamimMpelMrplnMaNPmi(taMtatf 

ifVWfiMB  WI101  vW  OW  W  IMWW  pBRDB  flBBBId  QMB  DOBBO* 
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Tim  JoBCsey 
(999)999-9999 


AccTKKcd  Sundardt  Comrmfiee 
aoerauig  under  cnc  orocedures  of  the 
Amcncen  Nebonal  Scendards  institute 

Document  No 

ASC  XUC/rG20/90-999 
June  2S.  1990 


Daa  Smithey 
(999)999-9999 


TO:  X12  Members  Who  Commented  on  Modificatioos  to 

Xlljot  Cootrol  Stnieturet 

RE:  Response  to  Commentt  on  December  Ballot 

DMs  20S289, 21S2S9. 317289 


Thank  you  for  your  comments.  This  ballot  involved  modificatiens  to  X12jtt.  Of  the  327  ballou  mailed,  153  ballots  were 
return^  Of  these,  81  approved,  15  approtod  with  »  20  diaappro«cd  with  comment  and  37  abmaiaed. 

In  feaeral,  the  vote  responses  were  in  fam  of  the  modificatioos.  The  maiocily  of  the  commeau  focused  on  the  impaa 
et  w  tli«  at  mfnmstMia  the  YITJa  The  proposed  SSOdificatioOS 

a»A  th>  M  tha  irntteay  k«vg  ttmetked  im  r>qin«i>  In  thasa  wmimwit*  A  revised 

modificatien  to  Xlljot  was  reviewed  by  Technical  Assessment  St  the  June  ASC  XUmeeiiat.  Modficatioos  to  the 
document  have  been  made  which  reflect  responses  to  the  commentt  from  this  ballot,  and  a  revised  copy  of  X12*t  is 
being  distributed  to  all  who  voted  on  this  issue,  (or  30-day  review  of  revisioas. 


Spedfle  responses  to  comments  follow. 


COMMENT:  Automobile  Corporation 

'Add  the  foOowing  note  to  Parapaph  3  J:  NOTE:  protoeol  charaoers  should  be  cmluded  from  the 

character  sec* 

RESPONSE: 

The  cover  letter  sent  out  with  the  votiaf  packife  e^laiaed  that  the  iateat  was  to  obtain  coasensHS  on  the  proposed 
modifications  to  X12jk  XUai  is  a  diflicult  standi  to  amend.  We  request  that  ballot  responses  be  coctudered  on  the 
merits  of  the  recommended  modficatioas  and  not  on  the  ttaadard  as  a  a4ole.  Your  comment  was  outside  the  scope  of 
the  requested  modifications. 
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COMMENT:  Airoaft  Corporatioe 

*Some  eoBsideratioa  for  Abatract  Syntax  Notation  One  (ASN.l)  ihould  be  allowed. 

1.  ASN.l  ia  capable  of  defining  all  of  the  neceaaaiy  inter-relationa  needed  by  X12  tranaactiona. 

1  ASN.l  requirea  leaa  characters  to  define  the  same  infomatioo. 

3.  ASN.l  ia  the  encoding  scheme  used  by  most  OSI  work.* 

RESPONSE: 

The  recommendation  to  consider  naage  of  ASN.1  encoding  reaches  far  beyond  the  scope  of  the  modifications  requested 
intbiabaUoL  Activitiea  such  as  this  are  beat  submitted  as  separate  work  requests. 

COMMENT:  Some  Software  Inc. 

*Conditionality  of  data  elements  should  be  left  to  the  discretioa  of  guidelines  agreements.  There  is 

much  dismssion  at  times  as  far  as  whether  certain  data  should  be  mandatory  or  not;  many  systems 

are  incapable  of  providing  certain  ‘mandatory*  information  and,  as  «■“*,  filler*type  «<«««  must  be  mserted.' 

RESPONSE: 

The  issue  of  d^  element  conditionality  as  a  whole  is  a  much  broader  subject  than  was  intended  to  be  addressed  within 
the  scope  of  this  ballot.  “Thk  h«ll««  mim*  to  « iii»«ii«  r«»  ^ 

already  cxistiag  conditional  structures.  If  the  heligwe*  tkt  tfc# 

the  standard,  the  task  group  recommends  that  this  be  submitted  as  a  separate  work  request 

Etc. 
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Accreted  Standanja  Commoae 

JoeSoaebody 

opereeng  ifider  the  procedurea  of  Ow 

Chair  TG19,X12C 

Anwrean  Naborwl  Standards  metma 

(999)999.9999 

Oocumenc  No 


ASC  X12CAC8/90-998A 
Augtttt  10, 1990 

Mt.  JaaeDoe 
Amcfieaa  Biak 
Ow  Ceatnl  Plan 
Middle  Aacfica.  MO  99999 

RE:  Reapooic  to  Ballot  Gwaarcatt  oa 
ASCXU  Model  Gaideliae 

Dear  Ma.  Doc: 

SahenMWliftiy  X12C  hat  emftmtmd  k«  T>«h  Awwip  19  tn  jiwiiAe  tA  ■t— *«  thi.  7^ 

■a«liefnrfTG19a>iihtathj«fcall  Yia  mmUt  tW  — <i  gum*  im»>  gw«UK—  We 

aapeciaOythaak  each  iadmdaal«4opravidedceaauaia,«hetkeria  approval  or  <aapprovai  of  the  guidefiae.  We 
raeofaiK  aad  appreciate  yoor  careful  review  of  thk  doataeaL 

Ow  reapoaae  ia  keyed  to  the  auabeied  heat  ia  the  ”»»■»—*«  attirhril  to  your  ballot 

RESPONSE 

LWeatreewhkyowooaaaeat  la  Sectioa  4JLZ  we  have  replaoed  utSa  rala  with ‘rulet  >  arc  atOoed*. 

1 TW  eoaAHioa  betwcea  Scetksa  4,13  aad  Sectioa  &2  oaly  cMttB  becaaa  of  the  cBMple  we  daae  a  the  fira 
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5.0  GLOSSARY 


This  chapter  contains  ASC  X12  and  DoD  specific  glossaries. 

5.1  X12  GLOSSARY 

ANSI 

American  National  Standards  Institute 
ANSI  Standard 

A  document  published  by  ANSI  that  has  been  approved  through 
the  consensus  process  of  public  announcement  and  review.  Each 
of  these  standards  must  have  been  developed  by  an  ANSI  commit¬ 
tee  and  must  be  revisited  by  that  committee  within  S  years  for 
update.  See  Draft  Standard  for  Trial  Use  (DSTU). 

Area  Transaction  Set 

Identifies  a  predefined  area  within  a  transaction  set  (header,  detail, 
summary)  containing  segments  and  their  various  attributes. 

ASC  X12 

Accredited  Standards  Committee,  X12  comprises  industry  mem¬ 
bers  who  create  EDI  standards  for  submission  to  ANSI  for  sub¬ 
sequent  approval  and  dissemination;  or  for  submission  to  the 
UN/ECE  for  approval  and  submission  of  UN/EDIFACT  stan-dards. 

Authentication 

A  mechanism  which  allows  the  receiver  of  an  electronic  transmis¬ 
sion  to  verify  the  sender  and  the  integrity  of  the  content  of  the 
transmission  through  the  use  of  an  electronic  “key”  or  algorithm 
which  is  shared  by  the  trading  partners.  This  is  sometimes  referred 
to  as  an  electronic  signature. 

Compliance  Checking 

A  checking  process  that  is  used  to  ensure  that  a  transmission 
complies  with  ANSI  X12  syntax  rules. 

Conditional  (C) 

A  data  element  requirement  designator  which  indicates  that  the 
presence  of  a  specified  data  element  is  dependent  on  the  value  or 
presence  of  other  data  elements  in  the  segment.  The  condition 
must  be  stated  and  must  be  computer  processable. 

Control  Segment 

A  Control  Segment  has  the  same  structure  as  a  Data  Segment  but 
is  used  for  transferring  control  information  for  grouping  data 
segments.  Control  Segments  are  Loop  Control  Segments  (LSA-E), 
Transaction  Set  Control  Segments  (ST/SE),  and  Functional  Group 
Control  Segments  (GS/GE),  defined  in  X12.6,  and  Interchange 
Control  Segments  flSA/IEA/TAl)  defined  in  X12.5. 
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Data  Element 

The  basic  units  of  information  in  the  EDI  standards  containing  a 
set  of  values  that  represent  a  singular  fact.  They  may  be  single¬ 
character  codes,  literal  descriptions,  or  numeric  values. 

Data  Element  Length 

This  is  the  range,  minimum  to  maximum,  of  the  number  of  char¬ 
acter  positions  available  to  represent  the  value  of  a  data  element. 
A  data  element  may  be  of  variable  length  with  range  from  mini¬ 
mum  to  maximum,  or  it  may  be  of  fixed  length  in  which  the 
minimum  is  equal  to  the  maximum. 

Data  Element  Reference  Number 

Reference  number  assigned  to  each  data  element  as  a  unique 
identifier. 

Data  Element  Requirement  Designator 
A  code  defrning  the  need  for  a  data  element  value  to  appear  in  the 
segment  if  the  segment  is  transmitted.  The  X12  codes  are  man¬ 
datory  (M),  optional  (O),  or  conditional  (C).  DoD  may  "require" 
a  segment  which  is  optional  by  X12  standards. 

Data  Element  Separator 

A  unique  character  preceding  each  data  element  that  is  used  to 
delimit  data  elements  within  a  segment.  Dod  uses  as  the 
delimiter. 

Data  Element  Type 

A  data  element  may  be  one  of  six  types:  numeric,  decimal, 
identifier,  string,  date,  or  time. 

Delimiters 

The  delimiters  consist  of  two  levels  of  separators  and  a  terminator. 
The  delimiters  are  an  integral  part  of  the  transferred  data  stream. 
Delimiters  are  specified  in  the  interchange  header  and  may  not  be 
used  in  a  data  element  value  elsewhere  in  the  interchange.  From 
highest  to  lowest  level,  the  separators  and  terminator  are  segment 
terminator  and  data  element  separator. 

DISA 

Data  Interchange  Standards  Association.  A  nonprofit  organization 
funded  by  ASC  X12  members  which  serves  as  the  Secretariat  for 
X12. 

DSTU 

Draft  Standard  for  Trial  Use.  Represents  a  document  approved  for 
publication  by  the  full  X12  committee  following  memlwrship  con¬ 
sensus  and  subsequent  resolution  of  negative  votes.  (Final  Report 
of  X12  Publications  Task  Group).  The  Draft  EDI  Standard  for 
Trial  Use  document  represents  an  ASC  X12  approved  standard  for 
use  prior  to  approval  by  ANSI.  See  ANSI  Standard. 
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EDI 

Electronic  Data  Interchange.  The  computer  application  to  com¬ 
puter  application  exchange  of  business  information  in  a  standard 
format. 

Electronic  Envelope 

Electronic  information  which  binds  together  a  set  of  transmitted 
documents  being  sent  from  one  sender  to  one  receiver. 

Element  Delimiter 

A  single-character  which  follows  the  segment  identifier  and 
separates  each  data  element  in  a  segment  except  the  last. 

Functional  Group 

A  group  of  one  or  more  transaction  sets  bounded  by  a  functional 
group  header  segment  and  a  functional  group  trailer  segment. 

Functional  Group  Segments 

GS/GE  segments  identify  a  specific  functional  group  of  documents 
such  as  purchase  orders. 

Industry  Conventions 

Defines  how  the  ASC  X12  standards  are  used  by  the  specific 
industry 

Industry  Guidelines 

Defines  the  EDI  environment  for  using  conventions  within  an 
industry.  It  provides  assistance  on  how  to  implement  X12  stand¬ 
ards. 

Interchange  Control  Segments 

ISA/IEA  segments  identify  a  unique  interchange  being  sent  from 
one  sender  to  one  receiver  (see  electronic  envelope). 

Interchange  Control  Structure 

The  interchange  header  and  trailer  segments  envelop  one  or  more 
functional  groups  or  interchange-related  control  segments  and  per¬ 
form  the  following  functions:  (1)  defines  the  data  element 
separators  and  the  data  segment  terminators,  (2)  identifies  the 
sender  and  receiver,  (3)  provides  control  information  for  the  inter¬ 
change,  wd  (4)  allows  for  authorization  and  security  information. 
(X12.5) 

Loop 

A  group  of  semantically  related  segments;  these  segments  may  be 
either  bounded  or  unbounded  (X12.6).  The  N1  loop  is  an  example 
of  a  loop,  which  includes  segments  N1  to  PER  for  name  and 
address  information. 

Mandatory  (M) 

A  data  element/segment  requirement  designator  which  indicates 
the  presence  of  a  specified  data  element  is  required. 
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Mapping 

The  process  of  identifying  the  standard  data  element’s  relationship 
to  application  data  elements. 

Max  Use 

Specifies  the  maximum  number  of  times  a  segment  can  be  used  at 
the  location  in  a  transaction  set 

Message 

Entire  data  stream  including  the  outer  envelope 
Optional  (O) 

A  data  element/segment  requirement  designator  which  indicates 
the  presence  of  a  specified  data  element/segment  is  at  the  option 
of  the  sending  pany  which  can  be  based  on  the  mutual  agreement 
of  the  interchange  parties. 

Qualifler 

A  data  element  which  identifies  or  defines  a  related  element,  set 
of  elements,  or  a  segment.  The  qualifier  contains  a  code  taken 
from  a  list  of  approved  codes. 

Repeating  Segment 

A  segment  that  may  be  used  more  than  once  at  a  given  location 
in  a  transaction  set.  See  Max  Use. 

Security 

System  screening  which  denies  access  to  unauthorized  useis  and 
protects  data  from  unauthorized  uses 

Segment 

Segments  consist  of  logically  related  data  elements  in  a  defined 
sequence.  A  data  segment  consists  of  a  segment  identifier,  one  or 
more  data  elements  each  preceded  by  an  element  separator,  and 
ends  with  a  segment  terminator. 

Segment  Directory 

Provides  the  purpose  and  format  of  the  segments  used  in  the 
construction  of  transaction  sets.  The  directory  lists  each  segment 
by  name,  purpose,  identifier,  the  contained  data  elements  in  the 
specified  order,  and  the  requirement  designator  for  each  data 
element. 

Segment  Identifier 

A  unique  identifier  for  a  segment  composed  of  a  combination  of 
two  or  three  upper-case  letters  and  digits.  The  segment  identifier 
occupies  the  first-character  positions  of  the  segment.  The  segment 
identifier  is  not  a  data  element.  The  segment  identifier  in 
EDIFACT  is  a  component  data  element  —  part  of  a  composite 
data  element  consisting  of  a  segment  identifier  and  an  explicit 
looping  designator. 
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Segment  Terminator 

A  unique  character  appearing  at  the  end  of  a  segment  to  indicate 
the  termination  of  the  segment,  e.g.,  N/L. 

Syntax 

The  grammar  or  rules  which  define  the  structure  of  the  EDI 
standards  (i.e.,  the  use  of  loops,  qualifiers,  etc.).  Syntax  rules  are 
published  in  ANSI  X12.6. 

Transaction  Set 

The  transaction  set  unambiguously  defines,  in  the  standard  syntax, 
information  of  business  or  strategic  significance  and  consists  of  a 
transaction  set  header  segment,  one  or  more  data  segments  in  a 
specified  order,  and  a  transaction  set  trailer  segment. 

Transaction  Set  ID 

An  identifier  that  uniquely  identifies  the  transaction  set.  This 
identifier  is  the  first  data  element  of  the  transaction  set  header 
segment. 

Translation 

The  act  of  accepting  documents  in  other  than  standard  format  and 
translating  them  to  the  standard. 

Version/Reiease 

Identifies  the  publication  of  the  standard  being  used  for  the  genera¬ 
tion  or  the  inteipretaiion  of  data  in  the  X12  standard  fonr.at.  May 
be  found  in  the  Functional  Group  Header  Segment  (GS)  and  in  the 
Interchange  Control  Header  Segment  (ISA).  See  Control  Segment. 

Vies  Committee 

Voluntary  Interindustry  Communications  Standards  for  Electronic 
Data  Interchange 

X12 

The  ANSI  committee  responsible  for  the  development  and  main¬ 
tenance  of  standards  for  electronic  data  interchange  (EDI). 

X12^ 

Interchange  Control  Structure.  This  standard  provides  the  inter¬ 
change  envelope  of  a  header  and  trailer  for  the  electronic  inter¬ 
change  through  a  data  transmission,  and  it  provides  a  structure  to 
acknowledge  the  receipt  and  processing  of  this  envelope. 

X12.6 

Application  Control  Structure.  This  standard  describes  the  control 
segments  used  to  envelop  loops  of  data  segments,  to  envelop 
transaction  sets,  and  to  envelop  groups  of  related  transaction  sets. 
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5.2  DoD  GLOSSARY 

AIS 

Automaied  Infomiation  Systems 
ASD(P&L) 

Assistant  Secretary  of  Defense  (Production  and  Logistics) 

DES 

Data  Encryption  Standard 
DISA 

Defense  Information  Systems  Agency 

DLA 

Defense  Logistics  Agency 

ISA 

Interchange  Control  Header  Identifier 
NIST 

National  Institute  of  Standards  and  Technology 
NTE 

Note  Identifier 
PLUS 

Protection  of  Logistics  Unclassified/Sensitive  Systems 

un/edifact 

EDIFACT;  Electronic  Data  Interchange  for  Administration,  Com¬ 
merce,  and  Transport 
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